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MILITARY DATA LINK INTEGRATION APPARATUS AND METHOD 

2 

4 BACKGROUND OF THE INVENTION 

6 Field of the Invention (Technical Field) : 

8 The present invention relates to digital messaging and more 

particularly to the integration of legacy and new mission display systems with 
10 the military data link radios and the implementation of the Link 16 message 

set defined by MIL-STD-6016 and associated message processing 
12 capabilities. 

14 Background Art : 

16 The military uses various tactical data link radios to send and receive 

digital voice and data between their air, land, sea and space vehicles, and 
18 command and control facilities. On each vehicle and in each command and 

control facility, these data link radios are interfaced to various mission 
20 computers and display systems. The data transmitted across these data link 

radios consists of messages, message formats, and message protocols 
22 defined by various message standards. The mission and display systems use 

the data contained in these messages from external sources and generate the 
24 data put into these messages sent to external systems. 

26 Some examples of military data link radios are UHF line of sight (LOS) 

radios, UHF DAMA SATCOM, EHF MDR SATCOM, HF radios, Joint Tactical 
28 Information Distribution System (JTIDS), Multi-function Information 

Distribution System (MIDS), and Joint Tactical Radio System (JTRS). Military 
30 data link message standards can be Link 4, Link 1 1 , Link 1 6, Link 22, and the 

Variable Message Format (VMF). Examples of mission and display systems 
32 are vehicle controls and displays equipment, mission computers, 

workstations, and network servers. 
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The Department of Defense (DoD) has recently selected the Link-16 
2 data link message set (in accordance with MIL-STD-6016) as the standard for 

use on military platforms for tactical data link operations. In addition, the DoD 
4 is currently developing the Joint Tactical Radio System (JTRS) to use as the 

standard data link radio system. Each existing (legacy) and future military 
6 platform will use the JTRS with the Link 16 message set for its tactical data 

link capability. 

8 

As outlined in the DoD Command, Control, Communications, 
10 Computers, and Intelligence (C4I) Joint Tactical Data Link Management Plan 

(dated June 2000), a wide range of legacy military platforms will be upgraded 
12 to incorporate the JTRS with the Link-16 message set through 2015 and 

beyond. These same legacy platforms are currently deployed with existing 
14 subsystems that generate information used by or consume information 

provided by various existing and disparate military data link systems. When 
16 the new JTRS equipment is introduced into these legacy platforms, there will 

be a need to interface the existing platform subsystems with the new JTRS 
18 equipment. Also, each existing subsystem will need to be upgraded to utilize 

the new and evolving Link 1 6 message set. 

20 

Since most of these existing platform subsystems were developed in 
22 the past, they either implement a subset of the Link 16 message set, or they 

implement a different and older data link message set such as Link 4 or Link 
24 11. Also, many existing subsystems were designed to interface with older 

data link radio equipment and are not compatible with the newer data link 
26 radio equipment and message processing protocols. Each of these prior art 

systems are point solutions unique to the specific platform they are 
28 implemented on, and they are each provided by a specific company. These 

point solutions include receive, transmit, and processing functions. Receive 
30 functions receive the message from the data link radio, decode the message 

data, and send the data to the appropriate subsystem. Transmit functions 
32 collect specific data from platform subsystems, encode the data into the 

proper message format, and send the message to the data link radio. 
34 Processing functions act on selected data elements to perform specific tasks 
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such as filtering, correlation, keeping track files, and other mission specific 
2 functions. Each solution only implements the subset of messages required for 

that platform's mission. When future changes are needed because the 
4 military wants to add, delete or modify specific messages and message 

processing for the platform, the military must return to the previous point 
6 solution company and pay them to implement the changes. Thus, the existing 

product solutions do not provide the military with the capability of modifying 
8 specific messages without a major product redesign on each unique platform. 

For example, on fighter aircraft the mission computer interfaces to the existing 
10 data link radio and performs the message processing for the message subset 

implemented on the specific fighter. The display system also processes those 
12 messages that contain situational awareness information, but tailors it for the 

specific fighter mission and display requirements. 

14 

There are many different implementations of data link integration used 
16 in the United States military aircraft as well as NATO countries. Each of these 

are point solutions that were designed specifically for the aircraft they are 
18 used on. A specific example is the Data Link Interface Processor (DLIP) 

provided by Thales Communications. However, these existing 
20 implementations do not offer the benefits of the Military Data Link Integration 

Application: 

22 • They only implement a subset of the full J-Series message set. 

• They are not user programmable. Any addition or deletion of messages or 
24 special message processing functions requires redesign of the operational 
software. 

26 • They do not use API databases to allow I/O re-configuration without 
modification. 

28 • They do not provide standard display system interfaces and video outputs. 

30 As a result, the upgrade costs for these existing platform subsystems 

will be enormous if traditional subsystem upgrade approaches are used. 

32 Traditional upgrade approaches involve point solutions and upgrades by 
different integrators on each platform application. A need exists for a 
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common and low cost military data link integration (MDLI) product that can be 
2 used in multiple and disparate platform applications. 

4 

6 SUMMARY OF THE INVENTION (DISCLOSURE OF THE INVENTIONS 

8 The present invention implements a common scalable design that can 

be used on each and every platform application. The invention implements 
10 the complete or full Link 16 J-Series message set with a database driven 

design so that the military user can control message activation, message 
12 deactivation, and message processing instructions for each platform 

application. The database used for this capability is created by and 
14 maintained by the military user. The military does not need to pay any 

company to do this for them. This allows the common MDLI product to work 
16 on each unique platform without the need to recompile the operational 

software. 

18 

The present invention implements a database driven design that allows 
20 automatic re-configuration of the MDLI product for each unique platform 

without the need for software changes to the product. The database used for 
22 this capability contains the interface instructions for each type of subsystem 

used on each unique platform and allows the common MDLI product to work 
24 on each unique platform without the need to recompile the operational 

software. 

26 

The present invention implements special message processing 
28 functions. These functions provide correlation of similar data from disparate 

sources, target track files, formatting of data into situational awareness 
30 display formats, automatic event triggers and associated actions, automatic 

triggers for transmit messages, mission recording and playback, and others. 
32 In addition, the present invention provides standard video outputs for Link 16 

display formats. 
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A primary object of the present invention is to provide a cpmmon 
2 scalable design that can be used on each and every platform application 

4 One advantage of the Military Data Link Integration Application is that it 

provides the military with a low cost solution. The user can tailor how the 

6 Military Data Link Integration Application works on each unique host platform 
simply by updating the Applications Programming Interface (API) Databases 

8 and User Modifiable Instructions (UMI) Databases. This gives the user 

control over the use and operation of the solution without the need to pay 
10 someone to modify it for them. 

12 Another advantage of the Military Data Link Integration Application is 

that it is flexible, scalable, and reusable for each unique host platform. 

14 Through the API Database it can be used on multiple unique host platforms to 
interface with available communications subsystems and legacy subsystems 

16 without any required modifications. 

18 Yet another advantage of the Military Data Link Integration Application 

is that it implements the complete set of Link 16 messages and processing 

20 rules defined in MIL-STD-601 6. The user can then activate or deactivate 
messages as required for each unique host platform. 

22 

Another advantage of the Military Data Link Integration Application is 
24 that it implements special message processing functions and utilities that can 

be activated or deactivated by the user. These message processing functions 
26 and utilities allow the user to add value to the data and messages sent by the 

Military Data Link Integration Application to available communications 
28 subsystems and legacy subsystems on the host platform. 

30 Another advantage of the Military Data Link Integration Application is 

that it provides standard display system interfaces to support flexible and user 

32 programmable display formats to view Link 1 6 data and legacy subsystem 
data. 
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Another advantage of the Military Data Link Integration Application is 
2 the Ground Based Software Tool that allows users to define and create the 
API Databases and UMI Databases on a workstation in an office environment. 

4 

Another advantage of the Military Data Link Integration Application 
6 common solution is that is saves the user money on training and maintenance 
costs across all host platforms. 

8 

Other objects, advantages and novel features, and further scope of 
10 applicability of the present invention will be set forth in part in the detailed 

description to follow, taken in conjunction with the accompanying drawings, 
12 and in part will become apparent to those skilled in the art upon examination 

of the following, or may be learned by practice of the invention. The objects 
14 and advantages of the invention may be realized and attained by means of 

the instrumentalities and combinations particularly pointed out in the 
16 appended claims. 

18 

BRIEF DESCRIPTION OF THE DRAWINGS 

20 

The accompanying drawings, which are incorporated into and form a 
22 part of the specification, illustrate several embodiments of the present 

invention and, together with the description, serve to explain the principles of 
24 the invention. The drawings are only for the purpose of illustrating a preferred 

embodiment of the invention and are not to be construed as limiting the 
26 invention. In the drawings: 

28 Fig. 1 depicts the military data link integration application implantation 

on a host processor; 
30 Fig. 2 is a flow chart that shows the preferred military data link 

integration application; 
32 Fig. 3 is a flow chart showing the data link message processing flow; 

Fig. 4 is a flow chart showing the data link platform integration 
34 processing flow; 
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Fig. 5 shows the military data link integration application hosted on a 
2 general purpose processor module; and 

Fig. 6 shows the military data link integration application hosted on an 
4 image processing module. 

6 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 
8 (BEST MODES FOR CARRYING OUT THE INVENTION) 

10 The Military Data Link Integration Application is a software partition that 

executes on a host processor. Fig. 1 illustrates how the Military Data Link 
12 Integration Application 100 software partition is implemented. This same 

implementation is envisioned for each platform in which the Military Data Link 
14 Integration Application is used. The Military Data Link Integration Application 

consists of the following functions: Data Link Message Processing 200, Data 
16 Link Platform Integration 400, Application Programming Interface (API) 

Database 300, Message Parameter Database 340, and User Modifiable 
18 Instructions (UMI) Database 350. These Military Data Link Integration 

Application functions (200 through 400) are implemented in a computer 
20 system available on each host platform. The host computer system is 

expected to consist of a Host Applications Processor 632 module, Legacy 
22 Image Processing Module (IPM) 634, Legacy Input and Output (I/O) Modules 

636, and a computer cabinet with the necessary Legacy Computer Module 
24 Interconnects 638. The Military Data Link Integration Application functions 

(200 through 400) execute on the Host Applications Processor 632 and 
26 interface with legacy software Mission Applications 630 that are also 

executing on the Host Applications Processor 632 through pre-defined API 
28 data exchange protocols in the API Database 300. The Military Data Link 

Integration Application functions (200 through 400) also interface with external 
30 Communications Subsystems 500 and other Legacy Subsystems 600 through 

the host computer system Legacy IPM 634, Legacy I/O Modules 636, and 
32 their associated Legacy Computer Module Interconnections 638. The pre- 
defined data exchange protocols consist of host computer system port 
34 addresses, message structures and formats, and data exchange command 



sequences. The Military Data Link Integration Application functions (200 
2 through 400) utilize these host computer resources (632, 634, 636 and 638) to 

exchange data with external subsystems (500 and 600) over pre-defined 
4 system interfaces Legacy I/O 660 and Link 16 Messages 550. Additionally, 

the Military Data Link Integration Application databases (300 and 350) can be 
6 created off the platform on a Ground Based Software Tool 700. These 

databases can then be uploaded to the Host Application Processor 632 
8 memory through a data loader within the Legacy Subsystems 600 using a 

Data Loader Cartridge 702. These databases (300 and 350) are used by the 
10 Data Link Message Processing 200 and Data Link Platform Integration 400 

functions to automatically configure the Military Data Link Integration 
12 Application on the host platform, and to implement user defined instructions. 

14 Fig. 2 illustrates the Military Data Link Integration Application 100 

approach consisting of its major functions Data Link Message Processing 200 
16 and Data Link Platform Integration 400. It also includes the API Database 

300, the Message Parameter Database 340, and the User Modifiable 
18 Instructions (UMI) Database 350. The Data Link Message Processing 200 

function implements the Link 16 message set with its processing rules and 
20 special message functions. It interfaces with the Communications 

Subsystems 500 on the host platform, databases (300, 340 and 350), and the 
22 Data Link Platform Integration 400 function. The Data Link Platform 

Integration 400 function implements the rules and instructions needed to 
24 interface with and interact with the various Legacy Subsystems 600 on the 

host platform, as well as Special Platform Functions 460, under the control of 
26 the Data Link Message Processing 200 function. Control is accomplished 

through the Control and Status Exchange 320 interface. The Data Link 
28 Platform Integration 400 function also implements the data loader function 

that is used to update the API Database 300 and the UMI Database 350 using 
30 the host platform's Data Loader 640 device. 

Fig. 3 provides the Data Link Message Processing 200 functional flow 
32 chart. The processing flow illustrated in Fig. 3 implements the functions 210 

through 260 identified on Fig. 2. The Automatically Configurable API 210 
34 function shown on Fig. 2 is implemented in processes 212 through 224 of Fig. 
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3. The Decode Messages 230 function shown on Fig. 2 is implemented in 
2 processes 230 and 232 of Fig. 3. The Encode Messages 240 function shown 

on Fig. 2 is implemented in processes 240 and 242 of Fig. 3. The function 
4 Standard Message Processing and Link 16 Network Management Rules per 

MIL-STD-6016 250 shown on Fig. 2 is implemented in processes 252 through 
6 256 of Fig. 3. The Special Message Functions 260 shown on Fig. 2 is 

implemented in process 260 of Fig. 3. 

8 

The Data Link Message Processing 200 function processing flow is as 
10 follows. As shown in Fig. 3, Startup 212 occurs after application of power 

when the Host Applications Processor 632 ( Fig. 1) initiates the execution of 
12 the Data Link Message Processing 200 function. The Initialize 

Communications Interface 214 task is executed to establish the interfaces to 
14 the Communications Subsystems 500 using pre-defined instructions in the 

Communications Equipment API 302 database obtained through the API 
16 Configurations 310 interface (Fig. 2). This database contains the instructions 

to identify which Communications Subsystems 500 are available on the host 
18 platform. The database also provides Host Applications Processor 632 

interface port addresses and protocols, message structures and formats, and 
20 command sequences to accomplish data exchange for each of the available 

communications subsystems (510 through 540). After initialization is 
22 complete, Receive Messages 216 task is executed to poll each available 

Communications Subsystem (510 through 540) for incoming Link 16 
24 Messages 550. These incoming messages are received into Receive 

Message Queue 222. Decode Messages 230 task is then executed to 
26 unpack each received message in Receive Message Queue 222 and extract 

the data contained within each message. The extracted data is placed in 
28 Receive Message Data 232 storage area. Process Input Data 252 task is 

then executed to process incoming Link 16 data in accordance with the 
30 message processing rules defined in MIL-STD-6016 254. All Link 16 

message processing rules are contained in MIL-STD-6016 Message Rules 
32 254 data storage area. Process Input Data 252 task uses pre-defined 

Message Processing Instructions 354 to determine which Link 16 messages 
34 have been activated for the host platform and then uses the appropriate MIL- 



— 9 — 



STD-6016 Message Rule 254 on received message data 232. Message 
2 parameters obtained from incoming data are stored in Message Parameter 

Database 340. Execute Special Message Functions 260 task is then 
4 executed. Execute Special Message Functions 260 task uses Data Collection 

Instructions 356 to identify data parameters to be collected from Legacy 
6 Subsystems 600 on the host platform. These collected data parameters are 

stored in Message Parameter Database 340. Execute Special Message 
8 Functions 260 task uses Message Processing Instructions 354 to activate 

utilities on user specified data parameters. These utilities include data fusion 
10 algorithms, creation and update of track files, creation and update of shared 

situational awareness (SSA) information, and other user defined data 
12 operations. The results of these utility operations are stored in Message 

Parameter Database 340. Execute Special Message Functions 260 task uses 
14 Routing Instructions 352 to identify data in Message Parameter Database 340 

to be sent to specific Legacy Subsystems 600 and Communications 
16 Subsystems 500. Execute Special Message Functions 260 task uses Display 

Format Instructions 358 to format selected data in Message Parameter 
18 Database 340 for display. Process Output Data 256 task is then executed. 

This task formats the data tagged in Message Parameter Database 340 for 
20 output to available Communications Subsystems 500. The tagged data is 

formatted in accordance with MIL-STD-6016 Message Rules 254, and then is 
22 placed in Transmit Message Data 242 buffer. Encode Messages 240 task is 

then executed to encode the output data into the appropriate message format 
24 and to place these formatted messages in Transmit Message Queue 224, 

Transmit Messages 218 task is then executed to send each transmit message 
26 to the appropriate Communications Subsystem (510, 520, 530, or 540). A 

check is made to decide if it is time to Shutdown 220. If not, then Data Link 
28 Message Processing 200 function repeats itself by starting again with Receive 

Message 216 task. This process is repeated at a pre-defined update rate. 
30 Otherwise, Data Link Message Processing 200 function is Shutdown 222. 

32 Fig. 4 provides the Data Link Platform Integration Processing 400 

functional flow chart. The processing flow illustrated in Fig. 4 implements the 
34 functions 410 through 460 identified on Fig. 2. Automatically Configurable 
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API 410 function (Fig. 2) is implemented in processes 412 through 424 of Fig. 
2 4. Decode Data 430 function (Fig. 2) is implemented in processes 430 and 

432 in Fig. 4. Encode Data 440 function (Fig. 2) is implemented in processes 
4 440 and 442 of Fig. 4. Function Rules and Instructions for Unique Host 

Platform Requirements 450 (Fig. 2) is implemented in processes 452 through 
6 456 of Fig. 4. Special Platform Functions 460 (Fig. 2) is implemented in 

process 460 of Fig. 4. 

8 

Data Link Platform Integration Processing 400 function processing flow 
10 is as follows. Startup 412 occurs after application of power when Host 

Applications Processor 632 (Fig. 1) initiates the execution of Data Link 
12 Platform Integration Processing 400 function. Initialize Legacy Interfaces 414 

task is executed to establish the interfaces to Legacy Subsystems 600 using 
14 pre-defined instructions in the Displays Equipment API 304 database, Mission 

Equipment API 306 database, and Platform Unique API 308 database using 
16 API Configurations 310 interface (Fig. 2). These databases contain the 

instructions to identify which Legacy Subsystems 600 are available on the 
18 host platform. These databases also provide Host Applications Processor 

632 interface port addresses and protocols, message structures and formats, 
20 and command sequences to accomplish data exchange for each of the 

available legacy subsystems (610 through 650). After initialization is 
22 complete, Receive Data 416 task is executed to poll each available Legacy 

Subsystem (610 through 650) for incoming Legacy I/O 660. The incoming 
24 data is received into Receive Data Queue 422. Decode Data 430 task is then 

executed to unpack each received data item in Receive Data Queue 422 and 
26 extract the data from the legacy subsystem message format. The extracted 

data is placed in Receive Data 432 buffer. Process Input Data 452 task is 
28 then executed to process incoming data in accordance with Platform 

Integration Rules 454. Process Input Data 452 task uses pre-defined 
30 Platform Application Instructions 360 to determine which legacy subsystems 

have been activated for the host platform and then uses the appropriate 
32 Platform Integration Rules 454 on Receive Data 432. Message parameters 

obtained from incoming data are stored in Message Parameter Database 340. 
34 Execute Special Platform Functions 460 task is then executed. Execute 
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Special Platform Functions 460 task uses Data Collection Instructions 356 to 
2 identify data parameters to be collected from Legacy Subsystems 600 on the 

host platform. These collected data parameters are stored in Message 
4 Parameter Database 340. Execute Special Platform Functions 460 task uses 

Platform Application Instructions 360 to activate utilities on user specified data 
6 parameters. These utilities include display applications, mission applications, 

and other user defined data operations. The results of these utility operations 
8 are stored in Message Parameter Database 340. Execute Special Platform 

Functions 460 task uses Display Format Instructions 358 to format selected 
10 data in Message Parameter Database 340 for display. Process Output Data 

456 task is then executed. This task formats the data tagged in Message 
12 Parameter Database 340 for output to available Legacy Subsystems 600. 

The tagged data is formatted in accordance with Platform Integration Rules 
14 454, and then is placed in Transmit Data 442 buffer. Encode Data 440 task is 

then executed to encode the output data into the appropriate message format 
16 and to place these formatted messages in Transmit Data Queue 424. 

Transmit Data 418 task is then executed to send each transmit data message 
18 to the appropriate Legacy Subsystem (610, 620, 630, 640 or 650). A check is 

made to determine if it is time to Shutdown 420. If not, then Data Link 
20 Platform Integration Processing 400 function repeats itself by starting again 

with Receive Data 416 task. This process is repeated at a pre-defined update 
22 rate. Otherwise, Data Link Platform Integration Processing 400 function is 

Shutdown 425. 

24 

A capability of the Military Data Link Integration Application is the ability 
26 to automatically initialize its interfaces to Communications Subsystems 500 on 

the host platform. This capability allows the Military Data Link Integration 
28 Application to be hosted on many different host platforms without the need to 

modify it for different communications equipment configurations. 
30 Automatically Configurable API 210, shown on Fig. 2, uses Communications 

Equipment API 302 database to obtain instructions to identify which 
32 Communications Subsystems (510 through 540) are available on the host 

platform. Communications Equipment API 302 database also provides Host 
34 Applications Processor 632 (Fig. 1) interface port addresses and protocols, 
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message structures and formats, and command sequences to accomplish 
2 data exchange for each of the available communications subsystems (510 

through 540). Communications Equipment API 302 database is created off 
4 the platform using Ground Based Software Tool 700 shown in Fig. 1 . Ground 

Based Software Tool 700 is provided on a workstation in an office 
6 environment. This tool is used to define the interface port addresses and 

protocols, message structures and formats, and command sequences to 
8 accomplish data exchange for each of the communications subsystems 

available on a specific platform and to create the associated Communications 
10 Equipment API 302 database for the host platform. This Communications 

Equipment API 302 database is then copied to a Data Loader Cartridge 702 
12 (Fig. 1 ). Data Loader Cartridge 702 is then used on the host platform to load 

Communications Equipment API 302 database into Military Data Link 
14 Integration Application API Database 300 storage area through host platform 

Data Loader 640 shown in Fig. 2. The instructions in Communications 
16 Equipment API 302 database are used by Initialize Communications Interface 

214 task (Fig. 3) to automatically configure Data Link Message Processing 
18 200 functions for the host platform communications subsystems (510 through 

540 in Fig. 2). Communications Equipment API 302 database is also used by 
20 Receive Messages 216 task and Transmit Messages 218 task to 

automatically configure these tasks to exchange incoming and outgoing 
22 messages with the available host platform communications subsystems (510 

through 540). 

24 Another capability of the Military Data Link Integration Application is the 

ability to automatically initialize its interfaces to Legacy Subsystems 600 on 
26 the host platform. This capability allows the Military Data Link Integration 

Application to be hosted on many different host platforms without the need to 
28 modify it for different legacy mission and displays equipment configurations. 

Automatically Configurable API 410 (Fig. 2) uses Displays Equipment API 304 
30 database, Mission Equipment API 306 database, and Platform Unique API 

308 database to obtain instructions to identify which legacy subsystems (610 
32 through 650) are available on the host platform. The databases (304, 306 

and 308) also provide Host Applications Processor 632 (Fig. 1) interface port 
34 addresses and protocols, message structures and formats, and command 
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sequences to accomplish data exchange for each of the available legacy 
2 subsystems (610 through 650). The instructions in the databases (304, 306 

and 308) are used by Initialize Legacy Interfaces 414 task, shown in Fig. 4, to 
4 automatically configure Data Link Platform Integration Processing 400 

functions for the host platform legacy subsystems (610 through 650 in Fig. 2). 
6 The databases (304, 306 and 308) are also used by Receive Data 41 6 task 

and Transmit Data 418 task to automatically configure these tasks to 
8 exchange incoming and outgoing data with the available host platform legacy 

subsystems (610 through 650). 

10 

Another capability of the Military Data Link Integration Application is the 
12 ability to implement user specified instructions associated with Link 16 

message processing and unique host platform functions. This capability 
14 allows the user to tailor how Link 16 messages are processed, to define 

special message processing functions, and to define special platform 
16 integration functions without the need to modify the Military Data Link 

Integration Application for each host platform configuration. Several 
18 databases are used to implement this capability. These databases, shown on 

Fig. 2, are Routing Instructions 352 database, Message Processing 
20 Instructions 354 database, Data Collection Instructions 356 database, Display 

Format Instructions 358 database, and Platform Application Instructions 360 
22 database. Routing Instructions 352 database provides instructions that 

identify data to be routed and the associated source and destination 
24 information. Source instructions identify the Link 16 message in which the 

data is contained or the legacy subsystem that provides the data. Destination 
26 instructions identify the Link 16 message in which the data is required or a 

legacy subsystem that required the data. Execute Special Message 
28 Functions 260 task, shown in Fig. 3, uses Routing Instructions 352 database 

to identify and tag source data in Message Parameter Database 340, shown 
30 in Fig. 2, to be sent to specific legacy subsystems (610 through 650) and 

communications subsystems (510 through 540). The source data tagged for 
32 Link 16 messages is then processed by Process Output Data 256 task (Fig. 

3), Encode Messages 240 task (Fig. 3) and Transmit Messages 218 task (Fig. 
34 3). This data is incorporated into Link 16 messages that are sent to the 
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available communications subsystems (510 through 540). The source data 
2 tagged for legacy subsystems is then processed by Process Output Data 456 

task (Fig. 4), Encode Data 440 task (Fig. 4) and Transmit Data 418 task (Fig. 
4 4). This data is incorporated into messages that are sent to the available 

legacy subsystems (610 through 650). Message Processing Instructions 354 
6 database provides instructions that identify which Link 16 messages to 

activate or deactivate, and which utility functions to activate for specific data 
8 items. Message Processing Instructions 354 database is used by Process 

Input Data 252 task, (Fig. 3), to identify which Link 16 messages have been 
10 activated for the host platform and then uses the appropriate MIL-STD-6016 

Message Rules 254 on received message data 232. Message parameters 
12 obtained from incoming messages are stored in Message Parameter 

Database 340. Execute Special Message Functions 260 task also uses 
14 Message Processing Instructions 354 database to activate utilities on user 

specified data parameters. These utilities include data fusion algorithms, 
16 creation and update of track files, creation and update of shared situational 

awareness (SSA) information, and other built-in data operations. The results 
18 of these utility operations are stored in Message Parameter Database 340. 

Data Collection Instructions 356 database provides instructions that identify 
20 what data is to be collected from the available communications subsystems 

(510 through 540) and legacy subsystems (610 through 650). Data Collection 
22 Instructions 356 database is used by Execute Special Message Functions 260 

task, (Fig. 3), to identify data parameters to be collected from available 
24 communications subsystems (510 through 540) on the host platform. These 

collected data parameters are stored in Message Parameter Database 340. 
26 Data Collection Instructions 356 database is also used by Execute Special 

Platform Functions 460 task, (Fig. 4), to identify data parameters to be 
28 collected from legacy subsystems (610 through 650) on the host platform. 

These collected data parameters are stored in Message Parameter Database 
30 340. Display Format Instructions 358 database provides instructions that 

identify what data needs to be formatted for display and what display formats 
32 to send to Display Subsystem 610. Display Format Instructions 358 database 

is used by Execute Special Message Functions 260 task (Fig. 3) to identify 
34 Link 16 message data in Message Parameter Database 340 that needs to be 
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formatted, and what formatting instruction to use. The formatted data is 
2 placed in Message Parameter Database 340. Display Format Instructions 

358 database is also used by Execute Special Platform Functions 460 task 
4 (Fig. 4) to identify legacy subsystem data in Message Parameter Database 

340 that needs to be formatted, and what formatting instruction to use. The 
6 formatted data is placed in Message Parameter Database 340. The formatted 

display data and selected display format information contained in Message 
8 Parameter Database 340 is then used by Process Output Data 456 task, 

Encode Data 440 task, and Transmit Data 418 task to send the formatted 
10 display data and selected display format information to Display Subsystem 

610 ( Fig. 2) oh the host platform. Platform Application Instructions 360 
12 database provides instructions that identify which platform utility functions to 

activate. Process Input Data 452 task (Fig. 4) uses pre-defined Platform 
14 Application Instructions 360 to determine which legacy subsystems have been 

activated for the host platform and then uses the appropriate Platform 
16 Integration Rules 454 on Receive Data 432. Message parameters obtained 

from incoming data are stored in Message Parameter Database 340. Execute 
18 Special Platform Functions 460 task also uses Platform Application 

Instructions 360 database to activate utilities on user specified data 
20 parameters. These utilities include display applications, mission applications, 

logic operations, preferred channel selections, service operational preference 
22 tables, mission record and playback, and other user defined data operations. 

The results of these utility operations are stored in Message Parameter 
24 Database 340. Another capability of the Military Data Link Integration 

Application is the ability to create its databases (302 through 308 and 352 
26 through 360) off the host platform using Ground Based Software Tool 700 

shown in Fig. 1 . Ground Based Software Tool 700 is provided on a 
28 workstation in an office environment. This tool is used to collect information, 

to define and create data and data structures, and to define and create the 
30 associated instructions required in each database (302 through 308 and 352 

through 360). Once created, the databases (302 through 308 and 352 
32 through 360) are then copied to a Data Loader Cartridge 702 (Fig. 1). Data 

Loader Cartridge 702 is then used on the host platform to load the individual 
34 databases (302 through 308 and 352 through 360) into API Database 300 
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storage area and UMI Database 350 storage area through host platform Data 
2 Loader 640 shown in Fig. 2. 

4 Since the Military Data Link Integration Application is a software 

partition, it can be implemented in an existing computer system on the host 

6 platform as illustrated in Fig. 1 . It can also be hosted on a General Purpose 
Processor module 680 illustrated in Fig. 5, or an Image Processing Module 

8 690 illustrated in Fig. 6. 

10 In Fig. 5 API Database 300 is used to define the interfaces between 

Military Data Link Integration Application and Mission Applications 630 

12 executing on Host Applications Processor 632. API Database 300 is also 

used to define the interfaces to Legacy IPM 634 and Legacy I/O Modules 636. 

14 

In Fig. 6 API Database 300 is used to define the interfaces between the 
16 Military Data Link Integration Application and Mission Applications 630 

executing on Host Applications Processor 632. API Database 300 is also 
18 used to define the interfaces to Legacy I/O Modules 636. Legacy IPM 634 is 

eliminated because it is replaced with Image Processing Module 690. 

20 

The advantage of hosting the Military Data Link Integration Application 
22 on a General Purpose Processor module or an Image Processing Module is 

that these provide more flexibility in implementing the Military Data Link 
24 Integration Application on host platforms that do not have an existing 

computer system. In the alternative, the existing computer system may not 
26 have the processing and memory resources required for the Military Data Link 

Integration Application. In these cases, the General Purpose Processor 
28 module or Image Processing Module can be integrated into any legacy 

subsystem equipment that has a spare card slot. 

30 

Although the invention has been described in detail with particular 
32 reference to these preferred embodiments, other embodiments can achieve 

the same results. Variations and modifications of the present invention will be 
34 obvious to those skilled in the art and it is intended to cover in the appended 
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claims all such modifications and equivalents. The entire disclosures of all 
references, applications, patents, and publications cited above, are hereby 
incorporated by reference. 



